Skip to main content

Process Engine

The main task of the process engine is the execution of all of the process models within the Orchestra runtime. Whenever a external event is received a process instance that belongs to one process model is started. A process instance is container that reflects the current state of the processing based on the process model.

Information that is held specific to a process instance are:

  • Current activity
  • Content of all variables related to the process instance

Due to the basic principle of loosely coupling, the process engine is designed as a passive component. This means, the process engine is only responsible for maintaining state and computing transitions of activities. The main task of execution an activity ( e.g. call to an external system) is not executed by the process engine itself. Rather to job is delegated to the underlying queuing component. The process engine creates a work item that is given to the queue engine for execution. When the execution has finished, the process engine is informed about the result. After that a transition is computed on basis of the process model. The result determines the next execution step of the process instance. On basis of this model a constant use of resources is guaranteed.

As described earlier, interfacing in heterogeneous system is a very difficult task. Due to the existence of different scenarios like synchronous or asynchronous the process engine itself has to be very flexible. In case of synchronous scenarios the performance and throughput are two important factory that have to be optimized. In order to have a high performance the overehead for maintaining state information has to be reduced to a minimum. On the other hand, in batch mode reliability and processing of mass data is more important.

Since this requirements are hard to solve with one approach, Orchestra supports different modes of operations.

  • Volatile: The state information of a process instance is only stored in memory. This guarantees a better performance since less time is necessary for persisting the information. This operating mode is useful for online interfaces's that need high throughput and reduced processing times. The disadvantage is that no restart is possible in case of a server shutdown or server crash. Furthermore, memory is a limiting factor in this model. If more memory is needed than currently available, Orchestra start unloading process from memory to the database. This is necessary since the software has to ensure permanent operations even when available memory is low.

  • Persistent: The state information of a process instance is stored within the Orchestra database. This guarantees, that in case of a system error the active process instances can continue. This mode is especially sensible with asynchronous, batch oriented processes because it guarantees complete processing even in case of a server crash.

  • Volatile with recovery: This mode is a combination of volatile and persistent. The processes are executed in volatile mode. In case of a server crash Orchestra ensures that the volatile process can be restarted again from the beginning. Therefor only the start parameters have to be persisted. This mechanism tries to balance the overhead between persistence and performance